Vehicles have been known to exchange data with external systems such as vehicle management systems and diagnostic computer systems (for example, in a repair garage, in a regulatory enforcement or toll-collection facility, and the like) wirelessly using infrared data links, through low-power data links using transponders, and using communications protocols such as the IEEE 802.11 family of protocols and Bluetooth® protocols.
More sophisticated and longer range vehicular telemetry for commercial fleets has been made possible through other terrestrial and even satellite communications. In these vehicular telemetry systems, navigational (e.g., GPS) and other vehicle sensor data can be logged and/or transported over wireless data links to a remote host computer that is programmed to monitor and record salient vehicular (e.g., automotive) data and to support database systems for vehicular tracking and/or for maintenance, without the attendant need for a vehicle to be in a particular service bay, for example. Driver behavior can also be similarly monitored.
The California Air Resources Board (“CARB”) has been at the forefront of establishing standards for monitoring vehicle emissions and influencing the development of electronic systems relating to same.
Early CARB requirements specified that all new vehicles sold in the United States in the state of California, beginning with the model year 1998, have some basic on-board diagnostics (“OBD”) capability. These early requirements are now generally referred to as OBD-I, although this designation was not specifically employed until the subsequent introduction of what then came to be known as OBD-II. No standards for a data link connector or a data transfer protocol were established at that time, however.
In 1988, the Society of Automotive Engineers (“SAE”) made recommendations concerning a standardized diagnostic connector and a set of diagnostic test or trouble code signals (“DTCs”). However, it was not until 1994 that CARB issued the OBD-II specification and mandated that it be adopted for all cars sold in California starting with model year 1996. The SAE-recommended DTCs and the standardized diagnostic connector were incorporated into this specification.
In 1996, the OBD-II specification was made mandatory by the US Environmental Protection Agency (“EPA”) for all cars sold in the United States.
A subsequent CARB initiative, widely known as OBD-III, represented a third generation of on-board diagnostic requirements calling for an emissions regulatory agency to remotely retrieve diagnostic data from vehicles.
An emissions-centric OBD telemetry system (e.g., computer(s), microcontroller(s), and sensor(s)) generally monitors a vehicle's emission control systems to detect any malfunction or deterioration that causes emissions to exceed EPA-mandated thresholds.
More generally, OBD-II telemetry systems, such as vehicle-manufacturer augmented diagnostic systems, monitor a wide range of types of data that indicate the performance of the host vehicle. For example, these data can be analyzed not only to infer the vehicle's emission performance, but also to monitor vehicle speed, mileage, engine temperature, intake manifold pressure, and a host of other manufacturer-specific data queries, such as data relating to the vehicle's engine, transmission, brakes, alarm, and entertainment systems. In total, such telemetry systems typically access more than 300 segments of data relating to the performance of the vehicle, and also acquires data on the particular model or “make” of the vehicle.
Typical implementations in post-1996 North American vehicles, for example, provide data and control access to electronic control units (“ECUs”) that control internal electromechanical actuators. Examples include ECUs that control fuel-injector pulses, spark-plug timing, and anti-lock braking systems. In many implementations, ECUs transmit status and diagnostic information over one or more shared standardized electronic communications buses associated with the vehicle in which the ECUs operate.
Such a bus arrangement effectively functions in an on-board computer network, bridging a variety of processors and sensors, each of which variously transmits and/or receives data. The primary computers in this network are the vehicle's electronic-control module (“ECM”) and power-train-control module (“PCM”). The ECM typically accesses other computers and microcontrollers that monitor and/or control engine functions (e.g., cruise-control module, spark controller, exhaust/gas recirculation for internal combustion engines). The PCM typically controls and/or monitors ECUs associated with the vehicle's power train (e.g., engine, transmission, and braking systems). In fuel cell or battery-powered vehicles (e.g., hybrids or the like), the battery's state of charge or remaining potential may be important aspects of the monitoring and/or performance data carried over the bus.
When a vehicle is to be serviced, data from the standardized bus can be queried using external engine-diagnostic equipment that connects to a standardized 16-cavity electrical connector (called an OBD-II connector for vehicles made after 1996). More specifically, the OBD-II specification provides for a standardized hardware interface in the form of a female 16-pin (2×8) J1962 connector. Unlike its predecessor OBD-I connector, which was sometimes found under the hood of the vehicle, the OBD-II connector is required to be within 2 feet of the steering wheel, unless an exemption is granted to the vehicle manufacturer, in which case the connector still would be within reach of the driver's seat).
Data transferred through the OBD-II connector to engine-diagnostic equipment reflect the operational status of the vehicle and provides insights into whether specific components are functioning properly and/or how the vehicle is being driven. This in turn facilitates efficient and cost-effective vehicle servicing and/or maintenance planning and activity management. In particular, this lends telemetry systems to uses in vehicle tracking and other fleet asset management applications, although such systems also can be advantageously employed in driver-performance management applications too.
One consideration in the communication of vehicular data through telemetry is the harvesting of the desired information at the right instance to effectively represent vehicular activity that is germane to the management purpose of interest. U.S. Pat. No. 6,636,790 describes a telematics device in which data transmissions are either periodically sent or randomly sent, or are made responsive to an extrinsically motivated query through a remote (i.e., extra-vehicular) server or terminal. None of these three strategies strictly correlate contemporaneous vehicular circumstances with the act of data transmission, nor do these strategies correlate the vehicle's current state with querying or data logging activity.
At best, periodic transmissions are performed at predetermined intervals chosen as a compromise between sufficiently frequent transmissions, intended to provide an approximation of time insights into the real-world operation of the vehicle, and at the same time minimizing the costs involved in making data calls, which can provide diminishing “information-added” returns when performed too frequently.
Randomly instigated data transmissions generally are not associated with an attempt to control costs and do not focus on operational events. Randomness can lead to large gaps in the timeline of telematics coverage of the vehicle's operation. While randomness in sampling for statistical quality control methodologies is a useful technique for mitigating some forms of statistical prejudice, its usefulness in non-statistical situations, such as detecting a problematic event in the ongoing operation of a particular vehicle, is questionable.
Extrinsic (e.g. remote or extra-vehicular) telematic queries typically are motivated without insight into the vehicle's current state of operation. The timing of such queries may be “non-random” to the extent and in the particular sense that they might be purposely driven in accordance with some predetermined management rationale. Initiation of extrinsic telematic queries, nevertheless, are detached or unrelated to the vehicle's contemporaneous operating condition. In this sense, such queries may be considered to be random, as that term is used herein.
U.S. Pat. No. 5,311,197—issued May 10, 1994, describes a vehicular telematics arrangement which does not rely on periodic, random or extrinsic events to transact telemetry logging or transmissions. Instead, this patent discloses an arrangement in which accident conditions or other abnormal events trigger the telemetry transactions for location and vehicle operational data. However, this telematics triggering arrangement only captures exceptional circumstances—and hence does not cover the normal, (i.e. “abnormal, non-accident related”) operations of the vehicle. Accordingly, both U.S. Pat. No. 5,311,197 and U.S. Pat. No. 6,636,790 fail to provide an efficient approach to telematics monitoring of a vehicle's normal operations.